Benchmark Results (4383-module project, mvn validate)

Added commit 568b44b that eliminates unnecessary builder.build() calls in pipeline stages by using targeted builder getters instead of full model materialization.

Changes

model.vm: Added getBuilt*() methods for model-object list fields. When the builder field is null (unmodified), returns base.getXxx() at zero cost. When modified, builds just that field's builders — avoids full model build.

5 pipeline stages fixed to avoid builder.build():

• DefaultPluginConfigurationExpander → builder.getBuild() / builder.getReporting()
• DefaultModelNormalizer (2 methods) → builder.getBuild() / builder.getBuiltDependencies()
• DefaultDependencyManagementInjector → builder.getDependencyManagement() / builder.getBuiltDependencies()
• DefaultPluginManagementInjector → builder.getBuild()
• DefaultModelPathTranslator → builder.getBuild() / builder.getReporting()

Results (3 runs each, average)

Performance is within run-to-run variance. The fix eliminates the unnecessary full-model materializations while maintaining the same performance level. All 1130 tests pass (550 in maven-impl, 580 in maven-core).

Updated benchmark: getModifiable() + two-field optimization

Following up on the previous fix — the pipeline stages now use getModifiable*() to work directly with mutable Dependency.Builder lists, mutating in place instead of round-tripping through immutable objects.

What changed (commit 443dcc5)

model.vm (two-field optimization):

• Builder now stores both Collection<X.Builder> (for getModifiable*()) and Collection<X> Imm (for the setter)
• The dependencies(Collection<Dependency>) setter stores the immutable list directly — zero wrapping overhead
• getModifiable*() lazily wraps from whichever source is set (immutable field, or base)
• build() constructor uses whichever field is set — immutable list path has no builder overhead
• forceCopy constructor stores immutable reference instead of wrapping

Pipeline stages (getModifiable pattern):

• DefaultModelNormalizer.injectDefaultValues — iterates getModifiableDependencies(), sets scope on builders in place
• DefaultModelNormalizer.mergeDuplicates — deduplicates builder list in place using management key computed from builder getters
• DefaultDependencyManagementInjector — new mergeManagementIntoBuilders() method merges managed dep fields (version, scope, type, classifier, systemPath, exclusions + locations) directly into Dependency.Builder objects

Cost model

Before (v1): each pipeline stage that touches deps does a full wrap + unwrap cycle:

builder.getBuiltDependencies()  → N unwrap allocations
builder.dependencies(newList)   → N wrap allocations

With 3 stages touching deps: 6N allocations per module (3 wraps + 3 unwraps)

After (v2): ONE lazy wrap + ONE final unwrap for the entire pipeline segment:

builder.getModifiableDependencies()  → lazy wrap (cached across stages)
  stage 1: modify builders in place   → 0 allocations
  stage 2: modify builders in place   → 0 allocations
  stage 3: modify builders in place   → 0 allocations
builder.build()                      → final unwrap

Total: 2N allocations per module (1 wrap + 1 unwrap)

Benchmark results (4383-module project, mvn validate --threads 1)

The v2 optimization delivers a clear 10% improvement over PR #12652 alone, and 34% over rc-6.

Branch: optimize-model-builder-pipeline-fix (commits 568b44b861 + 443dcc5b51)

JFR-guided optimization (v3): withImportedFrom + ConcurrentHashMap.newKeySet

JFR profiling on the 4383-module benchmark identified two remaining hotspots, now fixed in commit d30efb5:

CPU profile comparison (v2 → v3)

What was fixed

1. updateWithImportedFrom (was 35% of CPU)

Every BOM-imported dependency was rebuilt through Dependency.newBuilder(dep, true).importedFrom(loc).build() — triggering forceCopy (wraps all sub-lists into builders), build (unwraps back to immutable), and object pool interning — just to set one metadata field.

Added withImportedFrom(InputLocation) + private copy constructor to model.vm. Shares all model fields by reference, bypasses Builder and object pool entirely.

2. CopyOnWriteArraySet (was 6.6% of CPU)

ConsumerPomArtifactTransformer.deferDeleteFile() added to a CopyOnWriteArraySet<Path> → O(n) indexOfRange scan + array copy per add. With 4383 modules: O(n²). Replaced with ConcurrentHashMap.newKeySet() → O(1).

Wall-clock benchmark (4383 modules, mvn validate)

Wall-clock difference between v2 and v3 is within noise (~0.3s on a 14s benchmark) because:

• BOM import runs once on the root POM, not on the critical path for parallel child processing
• The parallel 4383-module build is I/O and scheduling dominated

The cumulative improvement from rc-6 baseline remains ~27% faster.